【速報】Amazon Redshift の障害を自動的に検出して別のAZで復旧する『Cross-AZ cluster recovery』が発表されました #reinvent

AWS re:Invent 2020

#ビッグデータ

#ビジネス

#Amazon Redshift

#AWS

石川覚

2020.12.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Cross-AZ cluster recoveryは、Amazon Redshiftを再配置（relocation）を使用して、データの損失やアプリケーションの変更なしに、クラスターを別のアベイラビリティーゾーン（AZ）に移動できる機能です。

今までお客様から、「Redshiftは冗長化できますか？」と100万回ぐらい質問されたので、明日から「Redshiftには、Cross-AZ cluster recoveryがありまして、、、」と言えるようになりそうです。

Cross-AZ cluster recoveryとは

嬉しすぎるので、もう一回いいますね。

この機能を用いることで、クラスターでサービスが中断された場合でも、影響を最小限に抑えて操作を続行できます。しかも、追加料金なしでこの機能を提供します。

Redshiftクラスターが新しいアベイラビリティーゾーンに再配置されると、新しいクラスターのエンドポイントは元のクラスターと同じになります。アプリケーションはエンドポイントに再接続し、変更やデータの損失なしに操作を続行できます。ただし、特定のアベイラビリティーゾーンでの潜在的なリソースの制約により、再配置が常に可能であるとは限りません。

この機能は、ra3.16xlarge、ra3.4xlarge、ra3.xlplusなどのRA3インスタンスタイプでのみサポートされます。RA3インスタンスは、耐久性のあるストレージレイヤーとしてRedshift Managed Storage（RMS）を使用いるので、最新データのコピーは、AWSリージョンの他のアベイラビリティーゾーンで常に利用できます。RA3の仕組みを利用することでコストを掛けずに、データを失うことなく、AmazonRedshiftクラスターを別のアベイラビリティーゾーンに再配置がされます。

どのように実現しているのか

クラスターの再配置を有効にすると、Redshiftクラスターはプロキシの背後に移行します。エンドポイントがプロキシになることで、クラスターのコンピューティングリソースへの場所に依存しないアクセスが実現します。移行により、クラスターが再起動され、クラスターが別のアベイラビリティーゾーンに再配置されると、新しいクラスターが新しいアベイラビリティーゾーンでオンラインに戻されている間に停止が発生するはずですが、プロキシが介在しているのでシステム停止には至らないという仕組みです。

再配置を有効にすると、エンドポイントの変更はありませんがIPアドレスが変更になるので、IPアドレスを使用している場合はご注意ください。

クラスタの再配置を有効にする方法

Amazon Redshiftコンソール、AWS CLI、およびAmazon Redshift APIから、クラスターの再配置を有効にして管理できます。

クラスタの再配置を有効にするには、複数のアベイラビリティーゾーンを含むサブネットグループを定義します。

再配置が完了したら、同じエンドポイントを使用してクラスターにアクセスします。Amazon Redshiftは、元のクラスターのコンピューティングリソースを削除し、それらをリソースプールに戻します。

クラスタの新規作成の場合

クラスタの作成画面の一番下にCluster relocationの有効化の設定が選べます。

既存クラスタの変更の場合

バックアップ詳細のセクションで、[編集]を選択します。Cluster relocationの有効化の設定が選べます。

クラスタの再配置を有効を試してみた

Amazon Redshiftコンソールを用いてクラスタの再配置を有効を試してみました。Cluster relocationを無効化から有効化に変更すると、あっけないぐらい速く、1分程度でRedshiftクラスタがプロキシの背後に移行が完了しました。

エンドポイントは以下のように変更されています。無効化状態ではエンドポイントは10.0.0.239のAレコードでしたが、プロキシの背後に移行後はVPC Peeringのようなエンドポイントに対するCNAMEとその10.0.0.213のAレコードに変更になりました。

[ec2-user@ip-10-0-0-247 ~]$ dig redshift-ra3xlplus.cwquxezuo2x1.ap-northeast-1.redshift.amazonaws.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.4 <<>> redshift-ra3xlplus.cwquxezuo2x1.ap-northeast-1.redshift.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32715
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;redshift-ra3xlplus.cwquxezuo2x1.ap-northeast-1.redshift.amazonaws.com. IN A

;; ANSWER SECTION:
redshift-ra3xlplus.cwquxezuo2x1.ap-northeast-1.redshift.amazonaws.com. 60 IN A 10.0.0.239

;; Query time: 1 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: 木 12月 10 12:58:23 UTC 2020
;; MSG SIZE  rcvd: 114

[ec2-user@ip-10-0-0-247 ~]$ dig redshift-ra3xlplus.cwquxezuo2x1.ap-northeast-1.redshift.amazonaws.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.4 <<>> redshift-ra3xlplus.cwquxezuo2x1.ap-northeast-1.redshift.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9715
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;redshift-ra3xlplus.cwquxezuo2x1.ap-northeast-1.redshift.amazonaws.com. IN A

;; ANSWER SECTION:
redshift-ra3xlplus.cwquxezuo2x1.ap-northeast-1.redshift.amazonaws.com. 50 IN CNAME vpce-06c371d723a22f963-cg36k4el.vpce-svc-040846678ae0ed6cc.ap-northeast-1.vpce.amazonaws.com.
vpce-06c371d723a22f963-cg36k4el.vpce-svc-040846678ae0ed6cc.ap-northeast-1.vpce.amazonaws.com. 50 IN A 10.0.0.213

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: 木 12月 10 13:02:03 UTC 2020
;; MSG SIZE  rcvd: 207
[ec2-user@ip-10-0-0-247 ~]$